Technical In-depth Analysis Of Korean Npc Server Bombing Logs And Recommendation Of Traceability Tools

1. incident confirmation and initial isolation

- purpose: to confirm whether it has been "bombed" (usually refers to a traffic or resource depletion attack) to avoid evidence destruction.
- steps: pause non-critical writes; enable read-only or restrict access without restarting the host; conduct traffic sampling of the affected services and record time points.
- note: keep system time synchronized (ntp) and record administrator operations to ensure the link is auditable.

2. evidence collection and evidence preservation (copy before writing)

- purpose: to ensure that logs, memory and network data can be used as the basis for subsequent analysis and legal evidence collection.
- steps: 1) pack the key log directory and calculate the hash (for example: tar -> sha256sum); 2) export the memory image (use lime or windows built-in tools if allowed); 3) copy the log to the isolated storage in a way of adding only and not deleting.
- compliance: record the operator, time and tool version of each step.

3. collect key log sources

- list: system logs (/var/log/syslog, messages, auth.log), application logs (nginx/apache, game service logs), firewall/ids logs, routers/load balancers, cloud platform flow log.
- practical operation: use scp/rsync or secure file transfer to copy the original log to the analysis host; prioritize exporting the relevant time window for large volumes of logs.

4. network packet capture and preliminary traffic analysis

- packet capture suggestion: use tcpdump on the boundary or target host for passive capture (example: tcpdump -i any -s 0 -w /tmp/capture.pcap). pay attention to fragmenting the capture file to avoid filling up the disk.
- initial screening: use tshark or zeek to extract high-frequency ips, ports, and traffic peak time points, and export toptalkers and session statistics.

5. log analysis and timeline construction

- tools: elk (elasticsearch+logstash+kibana) or splunk are used for log unification; you can first use the command line (grep/awk/jq) for quick screening.
- timeline: standardize timestamps according to utc or unified time zone, merge system/network/application events to form a sequence of events from before the attack to the follow-up, and mark key iocs (ip, user-agent, uri, session id).

6. indicator extraction and ioc production

- extraction: statistics of abnormal request rates, duplicate uris, abnormal country codes, a large number of failed logins in a short period of time, etc.
- generate: export reusable indicators as suricata rules, zeek scripts or siem ioc entries for subsequent detection and interception.

7. traceability process and tool recommendation (passive + active query)

- passive intelligence: use virustotal, abuseipdb, shodan, censys, passivetotal to query the history of malicious ip/domain names.
- bgp and whois: use ripestat/apnic/arin and other whois and bgp looking glass to check the source ip ownership and as path.
- active tool: first use ping/traceroute only for path confirmation (pay attention to legality). do not perform detection, which will cause greater traffic.

8. list of commonly used analysis and forensic tools

- network detection: zeek(bro), suricata, arkime(moloch).
- logging and visualization: elk stack, splunk.
- packet capture and in-depth analysis: tcpdump, wireshark, tshark, networkminer.
- intelligence platforms: virustotal, abuseipdb, shodan, passive dns, bgp looking glass.

9. disposal recommendations and mitigation measures

- rate limiting: do rate limiting, acl or black hole routing on the edge device (only works with isp).
- emergency rules: block malicious user-agent or abnormal uri on waf/load balancer; add confirmed malicious ip to the blacklist and continuously monitor it.
- long-term: deploy scalable traffic cleaning, cdn and anycast protection, set up perfect alarms and centralize logs.

10. collaborate with isps and law enforcement

- contact: submit the compiled timeline, packet capture and ioc to the upstream isp and network operator to request traffic cleaning or source intervention.
- legal: prepare a chain of evidence (hashes, operation records) to report to the police and cooperate with legal procedures, and comply with local laws and privacy regulations.

11. review and defense improvement

- review content: attack vector, success rate, business impact, detection delay and mitigation effect.
- improvements: updated playbook, strengthened monitoring thresholds, regular ddos emergency response drills, and increased log retention period and capacity.

12. faq 1 - how can i confirm whether this "bombing" is caused by ddos or a traffic surge caused by misconfiguration?

- answer: compare peak traffic source distribution and request characteristics; ddos usually manifests itself as a large number of scattered source ips, similar request patterns, or abnormally high connection rates; misconfiguration is mostly amplified by a small number of ips or normal user behavior. combined with tcpdump/zeek statistics on top talkers and request duplication, you can quickly judge.

13. faq 2 — how long do i need to keep the captured pcaps and logs?

- answer: at least keep it until the incident is completely closed and legal and internal audit requirements are completed. it is usually recommended to keep it for more than 90 days; key evidence (hashed) should be archived for a longer period of time for law enforcement or accountability.

14. faq 3 - what are the highest priority tools that need to be deployed immediately for quick response next time?

- answer: it is recommended to prioritize the deployment of centralized logging system (elk or splunk), passive network detection (zeek) and boundary traffic monitoring (netflow/vpc flow logs), which can significantly shorten detection and response time, and at the same time cooperate with automated alarm and rate limiting strategies.